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Remarks 

Claims 1 through 32 are pending in the Application. Claims 1, 8, 14, 20, 24 and 29 are 
amended herein. 

Claim Rejections under 35 U.S.C. $103 

The Office Action issued a final rejection of claims 1-3, 5, 7-9, 11-12, 14-17, 19-22, 24- 
26 and 28 through 31 under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 
6,122,514 to Spaur et al. (the Spaur reference) in view of US Patent No. 6,832,087 to Gwon, et 
al. (the Gwon reference). Applicants respectfully traverse this rejection because neither the 
Spaur reference nor the Gwon reference, either alone or in combination, disclose or suggest the 
requirements of the claims. 

Independent Claim 1 and Dependent Claims 2 through 7 

Neither the Spaur reference nor the Gwon reference disclose or suggest the 
requirements, inter alia, of claim 1 of, "when the Internet packet is being received when the 
channel scan request is received, scanning at least one other channel of the plurality of channels, 
but less than all of the plurality of channels; after scanning the at least one other channel, tuning 
to the one of the plurality of channels and transmitting at least one outbound Internet packet; and 
scanning at least another channel of the plurality of channels." 

As stated in paragraphs 9-11 of the specification, the present application discloses a 
problem with a wireless transceiver. The wireless transceiver (e.g., the client station) is required 
to occasionally scan the available channels to see whether there are other nodes with which to 
communicate (i.e., other channels are supporting data of interest to the wireless communication 
device). Because of the nature of wireless networks, the scanning process requires that the 
station to temporarily leave the channel that is supporting a current communication by tuning and 
listening to one or more different channels to determine if there is any interest in association with 
one of these other channels. A significant period of time is required to make such a 
determination for each channel. In many wireless local area networks (WLAN), multiple 
frequencies and/or network interface protocols may be used (e.g., IEEE 802.1 lb, IEEE 802.1 la, 
and/or IEEE 802.1 lg protocols), which increases the number of channels that must be scanned 
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and correspondingly increases the time it takes to scan all of the channels. While the time it takes 
to scan multiple channels over multiple network interface protocols, the data throughput 
performance impact on the station is modest. However, the data throughput for higher layer 
protocols, such as Transmission Control Protocol/Internet Protocol (TCP/IP) may be 
significantly impacted. Such a significant impact results because TCP/IP measures the time that 
expires from when a source sends a packet to a destination until the source receives an 
acknowledgement (ACK) from the destination that it received the packet. If the time is greater 
than expected (e.g., a few hundred milliseconds plus some tolerance that accounts for reasonable 
transmission time variations), TCP/IP may interpret this as congestion (i.e., the network 
infrastructure is overworked and is slow in transferring packets). When congestion is suspected, 
TCP/IP uses a multiplicative decrease congestion avoidance algorithm that dramatically reduces 
the transmission rate of packets from the source to the destination. When the congestion is 
reduced, TCP/IP uses a slow start algorithm that slowly increases the packet rate between the 
source and the destination. If the station is scanning other channels for a significant period of 
time (e.g., a few hundred milliseconds), TCP/IP may view this absence of support as congestion 
and evoke the multiplicative decrease congestion avoidance algorithm. As such, the TCP/IP 
throughput is unnecessarily reduced. 

The embodiment of the invention in claim 1 solves this problem by receiving a scan 
channel request of a plurality of channels that are in accordance with the network interface 
protocol. For example, the channels may be in accordance with IEEE 802.11a, IEEE 802.11b, 
and/or IEEE 802.1 lg or other protocol. The method then continues by determining whether an 
Internet packet is being received via one of the plurality of channels when the channel scan 
request is received (i.e., is a higher layer protocol supporting a current transmission). If so, the 
method continues by scanning at least one channel of the plurality of channels, but does not scan 
all of the plurality of channels at one time. The method continues after the scanning by tuning to 
the channel supporting the higher layer protocol communication to transmit at least one 
outbound Internet packet. The method then continues by scanning at least another channel of the 
plurality of channels. 
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With respect to the Spaur reference, the Office Action first cites Figure 5 A, items 170 
through 182 and column 13, line 67 through column 14, line 3 as disclosing requirements of 
claim 1 . However, the Office Action has incorrectly interpreted the Spaur reference. The Spaur 
reference with respect to Figure 5 A, Items 170 through 182 at column 13, lines 8 through 16 
states that: 

At step 170, a decision is made as to whether or not the particular information 
transfer is to be started immediately. If this decision is in the affirmative, the link 
selector 64 takes control to initiate the transfer using one or more selected 
network channels 34a-34n at step 174. If the decision is in the negative, the 
information to be transferred is buffered and the link scheduler 70 obtains the 
current location of the mobile unit having the communications system 10 at step 
178. The link scheduler 70 then determines the identity of other network channels 
that are becoming available for selection, based on current location of the mobile 
unit and the anticipated change in location of the mobile unit at step 182. The 
anticipated channels that are becoming available and their availability time is then 
provided, at step 186, to the link selector 64 for determining each of their 
suitability values. 

Thus, the Spaur reference discloses only determining whether to initiate transfer on one or more 
selected network channels or determining an identity of other network channels based on 
location of the mobile unit to transfer the particular information. This disclosure teaches away 
from the embodiment of claim 1 . The embodiment of claim 1 is not scanning to determine a new 
channel to transmit a packet on which it has received a packet. As stated in claim 1, "when the 
Internet packet is being received via one of the plurality of channels when the channel scan 
request is received, scanning at least one other channel of the plurality of channels, but less than 
all of the plurality of channels; after scanning the at least one other channel, tuning to the one of 
the plurality of channels to transmit at least one outbound Internet packet; and scanning at least 
another channel of the plurality of channels." 

The Office Action also cites column 13, line 67 through column 14, line 3 as disclosing 
requirements of claim 1 . Again, this Office Action has incorrectly taken a small portion of the 
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Spaur reference out of context and misinterpreted it. At column 13, lines 43 through column 14, 
line 3, the Spaur reference states: 

As part of the operational steps involving the link scheduler 70, a determination is 
made as to whether or not a currently utilized network channel might be 
unavailable or go off line before completion of the particular information transfer. 
In accordance with this function, at step 218, the current location of the mobile 
unit having the communications system 10 is obtained. At step 222, a 
determination is made as to when the currently utilized network channel will go 
off line. This determination uses the current location of the mobile unit and the 
anticipated change in position of the mobile unit using velocity information 
and/or route or schedule information that the mobile unit follows. . . . This 
information can be combined with location-related information regarding the next 
location node and the estimated time to travel to it. From this data, the link 
scheduler 70 can be used in determining that a particular channel will go off line, 
as well as network channels that will become available. After this determination is 
made, the link scheduler 70, at step 226, informs the link selector 64 of the date 
and time when the currently utilized network channel will go off line. The link 
selector 64 is able to use this information in controlling the switching from the 
currently used network channel to a new or different selected channel. 

Nowhere does the Spaur reference discuss a request for scanning channels or how scanning of 
the channels is performed when receiving an Internet packet on a channel. Thus, the Spaur 
reference fails to disclose the requirements, inter alia, of claim 1 of, "when the Internet packet is 
being received when the channel scan request is received, scanning at least one other channel of 
the plurality of channels, but less than all of the plurality of channels; after scanning the at least 
one other channel, tuning to the one of the plurality of channels to transmit at least one outbound 
Internet packet; and scanning at least another channel of the plurality of channels." 

The Gwon reference also fails to disclose or suggest the requirements, inter alia, of claim 
1 of, "when the Internet packet is being received when the channel scan request is received, 
scanning at least one other channel of the plurality of channels, but less than all of the plurality 
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of channels; after scanning the at least one other channel, tuning to the one of the plurality of 
channels to transmit at least one outbound Internet packet; and scanning at least another channel 
of the plurality of channels." The Gwon reference describes a procedure for minimizing the 
handoff latency resulting from standard Mobile IP handoff procedures, as stated at column 2, 
lines 36 through 39. As stated, at column 1, lines 35 through 47, two types of handoffs, L2 and 
L3 are described: 

"A handoff occurs when a MN moves from one radio AP to another. A mere 
change of radio AP is called a "Layer 2 (L2) handoff," which does not involve 
any Layer 3 (L3) signaling at the IP level. If the new radio access point is 
associated with a new subnet, i.e., if the MN moves from one subnet to another, a 
changing in routing reachability occurs and requires Layer 3 (L3) protocol action. 
This L3 protocol action is called a "L3 handoff and usually involves exchange of 
a series of IP messages that are used to update routing information for the MN to 
make sure that data destined to the MN is routed through the new subnet to the 
MN." 

The Gwon reference describes that in order to prevent L3 handoff latency, a pre-registration 
handoff method allows the L3 handoff to begin even before the L2 handoff begins, as stated at 
column 2, lines 57 through 65. As stated in column 4, lines 13 through 35, IP tunnels are 
established between a source node and a set of candidate nodes. The tunnels are used to forward 
data to the mobile node after a communication link between the mobile node and the source node 
goes down. Once a target node is identified from the candidate nodes, using the tunnel from the 
source node to the target node, the mobile node keeps IP data communication with the source 
node after the L2 handoff but before the L3 handoff. Again at column 9, lines 35 through 51 
cited in the Office Action, the Gwon reference states that: 

With the tunnel that remains up [between the old FA (oFA) and new FA (nFA)], 
the MN can receive data from the oFA while on the nFA's subnet. Thus, the 
tunnel between oFA and nFA allows the MN to continue using the oFA for data 
communication while on the nFA's subnet. . . . The MN must eventually perform 
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a formal Mobile IP registration illustrated in FIG. 1 after an L2 link with the nFA 
is established, but this can be delayed as required by the MN. Until the MN 
performs registration, a new FA and an old FA will setup and move a tunnel as 
required to give MN continued connectivity. 

Thus, the Gwon reference merely discloses tunneling to a MN from an old FA while on a new 
FA subnet before a form Mobile IP registration by the MN. The Gwon reference nowhere 
describes when the Internet packet is being received when the channel scan request is received, 
scanning at least one other channel of the plurality of channels, but less than all of the plurality 
of channels; after scanning the at least one other channel, tuning to the one of the plurality of 
channels to transmit at least one outbound Internet packet; and scanning at least another channel 
of the plurality of channels. As such, the Gwon reference fails to disclose the requirements of 
claim 1 . 

The combination of the references also fails to suggest the requirements of claim 1 . As 
explained above, both the Spaur reference and the Gwon reference merely disclose handoff 
procedures and fail to even disclose the requirements of claim 1 as explained above. In 
addition, there is no suggestion to revise the references to meet the requirements of claim 1 
because neither reference discloses or realizes the problems addressed by the embodiments of the 
present invention that if a station is scanning other channels for a significant period of time (e.g., 
a few hundred milliseconds), TCP/IP may view this absence of support as congestion and evoke 
the multiplicative decrease congestion avoidance algorithm. As such, the combination of the 
reference fails to suggest the requirements, inter alia, of claim 1 of, "when the Internet packet is 
being received when the channel scan request is received, scanning at least one other channel of 
the plurality of channels, but less than all of the plurality of channels; after scanning the at least 
one other channel, tuning to the one of the plurality of channels to transmit at least one outbound 
Internet packet; and scanning at least another channel of the plurality of channels." 

The dependent claims 2 through 7 add further patentable matter to Claim 1 and thus are 
further differentiated and patentable under 35 U.S.C. §103 over the Spaur reference in view of 
the Gwon reference. 
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Independent Claim 8 and Dependent Claims 9 through 13 

Neither the Spaur reference nor the Gwon reference disclose or suggest the requirements, 
inter alia, of claim 8 of, "when a Transmission Control Protocol (TCP) connection is established 
between a source and a destination, receiving a network interface protocol channel scan request; 
and when the network interface protocol channel scan request is received, hopping between a 
channel supporting the TCP connection within a wireless local area network (WLAN) and other 
channels of the WLAN and transmitting on the channel supporting the TCP connection to avoid 
excess latency in acknowledging receipt of a packet formatted in accordance with the Internet 
Protocol or a portion of the packet during scanning of the other channels of the WLAN." 

With respect to the Spaur reference and claim 8, the Office Action cites on pages 9 and 
10 of the Office action, Figure 5 A, items 170 through 182 and column 13, line 67 through 
column 14, line 3, as disclosing requirements of claim 8. However, the Office Action has 
incorrectly interpreted the Spaur reference. The Spaur reference with respect to Figure 5 A, Items 
170 through 182 at column 13, lines 8 through 16 states that: 

At step 170, a decision is made as to whether or not the particular information 
transfer is to be started immediately. If this decision is in the affirmative, the link 
selector 64 takes control to initiate the transfer using one or more selected 
network channels 34a-34n at step 174. If the decision is in the negative, the 
information to be transferred is buffered and the link scheduler 70 obtains the 
current location of the mobile unit having the communications system 10 at step 
178. The link scheduler 70 then determines the identity of other network channels 
that are becoming available for selection, based on current location of the mobile 
unit and the anticipated change in location of the mobile unit at step 182. The 
anticipated channels that are becoming available and their availability time is then 
provided, at step 186, to the link selector 64 for determining each of their 
suitability values. 

The Spaur reference discloses that no transfer of information occurs until the link scheduler 70 
determines the identity of other network channels that are becoming available for selection, 
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based on current location of the mobile unit and the anticipated change in location of the mobile 
unit, at column 13, lines 8 through 16. Thus, the Spaur reference discloses only determining 
whether to initiate transfer on one or more selected network channels or determining an identity 
of other network channels based on location of the mobile unit to transfer the particular 
information. This aspect of the Spaur reference actually teaches away from the embodiment in 
claim 8 of, "when the network interface protocol channel scan request is received, hopping 
between a channel supporting the TCP connection within a wireless local area network (WLAN) 
and other channels of the WLAN to avoid excess latency in acknowledging receipt of a packet 
formatted in accordance with the Internet Protocol or a portion of the packet during scanning of 
the other channels of the WLAN. " The Office Action also cites column 13, line 67 through 
column 14, line 3 as disclosing requirements of claim 8. Again, this Office Action has 
incorrectly taken a small portion of the Spaur reference out of context and misinterpreted the 
Spaur reference. At column 13, lines 43 through column 14, line 3, the Spaur reference states: 

As part of the operational steps involving the link scheduler 70, a determination is 
made as to whether or not a currently utilized network channel might be 
unavailable or go off line before completion of the particular information transfer. 
In accordance with this function, at step 218, the current location of the mobile 
unit having the communications system 10 is obtained. At step 222, a 
determination is made as to when the currently utilized network channel will go 
off line. This determination uses the current location of the mobile unit and the 
anticipated change in position of the mobile unit using velocity information 
and/or route or schedule information that the mobile unit follows. . . . This 
information can be combined with location-related information regarding the next 
location node and the estimated time to travel to it. From this data, the link 
scheduler 70 can be used in determining that a particular channel will go off line, 
as well as network channels that will become available. After this determination is 
made, the link scheduler 70, at step 226, informs the link selector 64 of the date 
and time when the currently utilized network channel will go off line. The link 
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selector 64 is able to use this information in controlling the switching from the 
currently used network channel to a new or different selected channel. 

Thus, the Spaur reference nowhere discloses how scanning of other channels is performed or 
hopping between a channel supporting the TCP connection within a wireless local area network 
(WLAN) and other channels of the WLAN to avoid excess latency. Thus, the Spaur reference 
fails to disclose the requirements, inter alia, of claim 8 of, "hopping between a channel 
supporting the TCP connection within a wireless local area network (WLAN) and other channels 
of the WLAN to avoid excess latency in acknowledging receipt of a packet formatted in 
accordance with the Internet Protocol or a portion of the packet during scanning of the other 
channels of the WLAN." 

The Gwon reference also fails to disclose or suggest the requirements, inter alia, of claim 
8 of, "hopping between a channel supporting the TCP connection within a wireless local area 
network (WLAN) and other channels of the WLAN to avoid excess latency in acknowledging 
receipt of a packet formatted in accordance with the Internet Protocol or a portion of the packet 
during scanning of the other channels of the WLAN." The Gwon reference describes a 
procedure for minimizing the handoff latency resulting from standard Mobile IP handoff 
procedures, as stated at column 2, lines 36 through 39. The Gwon reference describes that in 
order to prevent L3 handoff latency, a pre -registration handoff method allows the L3 handoff to 
begin even before the L2 handoff begins, as stated at column 2, lines 57 through 65. As stated in 
column 4, lines 13 through 35, IP tunnels are established between a source node and a set of 
candidate nodes. The tunnels are used to forward data to the mobile node after a communication 
link between the mobile node and the source node goes down. Once a target node is identified 
from the candidate nodes, using the tunnel from the source node to the target node, the mobile 
node keeps IP data communication with the source node after the L2 handoff but before the L3 
handoff. Again at column 9, lines 35 through 51, the Gwon reference explains that: 

With the tunnel that remains up [between the old FA (oFA) and new FA (nFA)], 
the MN can receive data from the oFA while on the nFA's subnet. Thus, the 
tunnel between oFA and nFA allows the MN to continue using the oFA for data 
communication while on the nFA's subnet. . . . The MN must eventually perform 
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a formal Mobile IP registration illustrated in FIG. 1 after an L2 link with the nFA 
is established, but this can be delayed as required by the MN. Until the MN 
performs registration, a new FA and an old FA will setup and move a tunnel as 
required to give MN continued connectivity. 

Thus, the Gwon reference merely discloses tunneling to a MN from an old FA while on a new 
FA subnet before a form Mobile IP registration by the MN. As such, the Gwon reference fails to 
disclose the requirements, inter alia, of claim 8 of, "hopping between a channel supporting the 
TCP connection within a wireless local area network (WLAN) and other channels of the WLAN 
to avoid excess latency in acknowledging receipt of a packet formatted in accordance with the 
Internet Protocol or a portion of the packet during scanning of the other channels of the WLAN." 

The combination of the references also fails to suggest the requirements of claim 8. As 
explained above, both the Spaur reference and the Gwon reference merely disclose handoff 
procedures and fail to even disclose the requirements of claim 8 as explained above. In 
addition, there is no suggestion to revise the references to meet the requirements of claim 8 
because neither reference discloses or realizes the problems addressed by the embodiments of the 
present invention that if a station is scanning other channels for a significant period of time (e.g., 
a few hundred milliseconds), TCP/IP may view this absence of support as congestion and evoke 
the multiplicative decrease congestion avoidance algorithm. As such, the combination of the 
reference fails to suggest the requirements, inter alia, of claim 8 of, "hopping between a channel 
supporting the TCP connection within a wireless local area network (WLAN) and other channels 
of the WLAN to avoid excess latency in acknowledging receipt of a packet formatted in 
accordance with the Internet Protocol or a portion of the packet during scanning of the other 
channels of the WLAN." 

The dependent claims 9 through 13 add further patentable matter to Claim 8 and thus are 
further differentiated and patentable under 35 U.S.C. §103 over the Spaur reference in view of 
the Gwon reference. 

Independent Claim 14 and Dependent Claims 15 through 19 

Neither the Spaur reference nor the Gwon reference disclose or suggest the requirements, 
inter alia, of claim 14 of, "memory operably coupled to the processing module, wherein the 
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memory stores operational instructions that cause the processing module to: . . . generate a 
channel scan request in accordance with the transport application; determine whether one of the 
datagrams is being received when the channel scan request is generated; when the one of the 
datagrams is being received when the channel scan request is received, scan at least one other 
channel of the plurality of channels, but less than all of the plurality of channels; after scanning 
the at least one other channel, tune to the one of the plurality of channels and transmitting at least 
one outbound datagram; and scanning at least another channel of the plurality of channels." 

With respect to the Spaur reference, the Office Action on page 15 cites Figure 5 A, items 
170 through 182 and column 13, line 67 through column 14, line 3 of the Spaur reference as 
disclosing requirements of claim 14. However, the Office Action has incorrectly interpreted the 
Spaur reference. The Spaur reference with respect to Figure 5 A, Items 170 through 182 at 
column 13, lines 8 through 16 states that: 

At step 170, a decision is made as to whether or not the particular information 
transfer is to be started immediately. If this decision is in the affirmative, the link 
selector 64 takes control to initiate the transfer using one or more selected 
network channels 34a-34n at step 174. If the decision is in the negative, the 
information to be transferred is buffered and the link scheduler 70 obtains the 
current location of the mobile unit having the communications system 10 at step 
178. The link scheduler 70 then determines the identity of other network channels 
that are becoming available for selection, based on current location of the mobile 
unit and the anticipated change in location of the mobile unit at step 182. The 
anticipated channels that are becoming available and their availability time is then 
provided, at step 186, to the link selector 64 for determining each of their 
suitability values. 

The Spaur reference discloses that no transfer of information occurs until the link scheduler 70 
determines the identity of other network channels that are becoming available for selection, 
based on current location of the mobile unit and the anticipated change in location of the mobile 
unit, at column 13, lines 8 through 16. Thus, the Spaur reference discloses only determining 
whether to initiate transfer on one or more selected network channels or determining an identity 
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of other network channels based on location of the mobile unit to transfer the particular 
information. This aspect of the Spaur reference actually teaches away from claim 14, of, 
"memory operably coupled to the processing module, wherein the memory stores operational 
instructions that cause the processing module to: . . . when the one of the datagrams is being 
received when the channel scan request is received, scan at least one other channel of the 
plurality of channels, but less than all of the plurality of channels; after scanning the at least one 
other channel, tune to the one of the plurality of channels to transmit at least one outbound 
datagram; and scanning at least another channel of the plurality of channels." 

The Office Action also cites column 13, line 67 through column 14, line 3 as disclosing 
requirements of claim 14. Again, this Office Action has incorrectly taken a small portion of the 
Spaur reference out of context and misinterpreted the Spaur reference. At column 13, lines 43 
through column 14, line 3, the Spaur reference states: 

As part of the operational steps involving the link scheduler 70, a determination is 
made as to whether or not a currently utilized network channel might be 
unavailable or go off line before completion of the particular information transfer. 
In accordance with this function, at step 218, the current location of the mobile 
unit having the communications system 10 is obtained. At step 222, a 
determination is made as to when the currently utilized network channel will go 
off line. This determination uses the current location of the mobile unit and the 
anticipated change in position of the mobile unit using velocity information 
and/or route or schedule information that the mobile unit follows. . . . This 
information can be combined with location-related information regarding the next 
location node and the estimated time to travel to it. From this data, the link 
scheduler 70 can be used in determining that a particular channel will go off line, 
as well as network channels that will become available. After this determination is 
made, the link scheduler 70, at step 226, informs the link selector 64 of the date 
and time when the currently utilized network channel will go off line. The link 
selector 64 is able to use this information in controlling the switching from the 
currently used network channel to a new or different selected channel. 
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Thus, the Spaur reference nowhere even discloses a request for scanning or how scanning of the 
channels is performed. Thus, the Spaur reference fails to disclose the requirements, inter alia, of 
claim 14 of, "memory operably coupled to the processing module, wherein the memory stores 
operational instructions that cause the processing module to: . . . when the one of the datagrams 
is being received when the channel scan request is received, scan at least one other channel of the 
plurality of channels, but less than all of the plurality of channels; after scanning the at least one 
other channel, tune to the one of the plurality of channels to transmit at least one outbound 
datagram; and scanning at least another channel of the plurality of channels." 

The Gwon reference also fails to disclose or suggest the requirements, inter alia, of claim 
14 of, "memory operably coupled to the processing module, wherein the memory stores 
operational instructions that cause the processing module to: . . . when the one of the datagrams 
is being received when the channel scan request is received, scan at least one other channel of the 
plurality of channels, but less than all of the plurality of channels; after scanning the at least one 
other channel, tunc to the one of the plurality of channels to transmit at least one outbound 
datagram; and scanning at least another channel of the plurality of channels." The Gwon 
reference describes a procedure for minimizing the handoff latency resulting from standard 
Mobile IP handoff procedures, as stated at column 2, lines 36 through 39. The Gwon reference 
describes that in order to prevent L3 handoff latency, a pre -registration handoff method allows 
the L3 handoff to begin even before the L2 handoff begins, as stated at column 2, lines 57 
through 65. As stated in column 4, lines 13 through 35, IP tunnels are established between a 
source node and a set of candidate nodes. The tunnels are used to forward data to the mobile 
node after a communication link between the mobile node and the source node goes down. Once 
a target node is identified from the candidate nodes, using the tunnel from the source node to the 
target node, the mobile node keeps IP data communication with the source node after the L2 
handoff but before the L3 handoff. Again at column 9, lines 35 through 51, the Gwon reference 
states that: 

With the tunnel that remains up [between the old FA (oFA) and new FA (nFA)], 
the MN can receive data from the oFA while on the nFA's subnet. Thus, the 
tunnel between oFA and nFA allows the MN to continue using the oFA for data 
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communication while on the nFA's subnet. . . . The MN must eventually perform 
a formal Mobile IP registration illustrated in FIG. 1 after an L2 link with the nFA 
is established, but this can be delayed as required by the MN. Until the MN 
performs registration, a new FA and an old FA will setup and move a tunnel as 
required to give MN continued connectivity. 

Thus, the Gwon reference merely discloses tunneling to a MN from an old FA while on a new 
FA subnet before a form Mobile IP registration by the MN. As such, the Gwon reference fails to 
disclose the requirements, inter alia, of claim 14 of, "memory operably coupled to the processing 
module, wherein the memory stores operational instructions that cause the processing module to: 
. . . when the one of the datagrams is being received when the channel scan request is received, 
scan at least one other channel of the plurality of channels, but less than all of the plurality of 
channels; after scanning the at least one other channel, tune to the one of the plurality of channels 
to transmit at least one outbound datagram; and scanning at least another channel of the plurality 
of channels." 

The combination of the references also fails to suggest the requirements of claim 14. 
There is no suggestion to revise the references to meet the requirements of claim 14 because 
neither reference discloses or realizes the problems addressed by the embodiments of the present 
invention that if a station is scanning other channels for a significant period of time (e.g., a few 
hundred milliseconds), TCP/IP may view this absence of support as congestion and evoke the 
multiplicative decrease congestion avoidance algorithm. As such, the combination of the 
reference fails to suggest the requirements, inter alia, of claim 14 of, "memory operably coupled 
to the processing module, wherein the memory stores operational instructions that cause the 
processing module to: . . . when the one of the datagrams is being received when the channel 
scan request is received, scan at least one other channel of the plurality of channels, but less than 
all of the plurality of channels; after scanning the at least one other channel, tune to the one of 
the plurality of channels to transmit at least one outbound datagram; and scanning at least 
another channel of the plurality of channels." 
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The dependent claims 15 through 19 add further patentable matter to Claim 14 and thus 
are further differentiated and patentable under 35 U.S.C. §103 over the Spaur reference in view 
of the Gwon reference. 

Independent Claim 20 and Dependent Claims 21 through 23 

Neither the Spaur reference nor the Gwon reference disclose or suggest the requirements, 
inter alia, of claim 20 of, "memory operably coupled to the processing module, wherein the 
memory stores operational instructions that cause the processing module to: . . . process the 
packet in accordance with an Internet Protocol to produce at least one of the datagram; when a 
Transmission Control Protocol (TCP) connection is established between a source and the 
communication device, generate a network interface protocol channel scan request; and when 
the network interface protocol channel scan request is received, hop between a channel 
supporting the TCP connection within the WLAN and other channels of the WLAN and 
transmitting on the channel supporting the TCP connection to avoid excess latency in 
acknowledging receipt of a datagram of the at least one datagrams or a portion of the datagram 
during scanning of the other channels of the WLAN." 

With respect to the Spaur reference, the Office Action cites on pages 19 and 20 of the 
Office action, Figure 5 A, items 170 through 182 and column 13, line 67 through column 14, line 
3, as disclosing requirements of claim 20. However, the Office Action has incorrectly 
interpreted the Spaur reference. The Spaur reference with respect to Figure 5 A, Items 170 
through 182 at column 13, lines 8 through 16 states that: 

At step 170, a decision is made as to whether or not the particular information 
transfer is to be started immediately. If this decision is in the affirmative, the link 
selector 64 takes control to initiate the transfer using one or more selected 
network channels 34a-34n at step 174. If the decision is in the negative, the 
information to be transferred is buffered and the link scheduler 70 obtains the 
current location of the mobile unit having the communications system 10 at step 
178. The link scheduler 70 then determines the identity of other network channels 
that are becoming available for selection, based on current location of the mobile 
unit and the anticipated change in location of the mobile unit at step 182. The 
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anticipated channels that are becoming available and their availability time is then 
provided, at step 186, to the link selector 64 for determining each of their 
suitability values. 

The Spaur reference discloses that no transfer of information occurs until the link scheduler 70 
determines the identity of other network channels that are becoming available for selection, 
based on current location of the mobile unit and the anticipated change in location of the mobile 
unit, at column 13, lines 8 through 16. Thus, the Spaur reference discloses only determining 
whether to initiate transfer on one or more selected network channels or determining an identity 
of other network channels based on location of the mobile unit to transfer the particular 
information. This aspect of the Spaur reference actually teaches away from the embodiment in 
claim 20 of, "memory operably coupled to the processing module, wherein the memory stores 
operational instructions that cause the processing module to: . . . when the network interface 
protocol channel scan request is received, hop between a channel supporting the TCP connection 
within the WLAN a wireless local area network (WLAN) and other channels of the WLAN to 
avoid excess latency in acknowledging receipt of a datagram of the at least one datagrams or a 
portion of the datagram during scanning of the other channels of the WLAN." The Office 
Action also cites column 13, line 67 through column 14, line 3 as disclosing requirements of 
claim 20. Again, this Office Action has incorrectly taken a small portion of the Spaur reference 
out of context and misinterpreted the Spaur reference. At column 13, lines 43 through column 
14, line 3, the Spaur reference states: 

As part of the operational steps involving the link scheduler 70, a determination is 
made as to whether or not a currently utilized network channel might be 
unavailable or go off line before completion of the particular information transfer. 
In accordance with this function, at step 218, the current location of the mobile 
unit having the communications system 10 is obtained. At step 222, a 
determination is made as to when the currently utilized network channel will go 
off line. This determination uses the current location of the mobile unit and the 
anticipated change in position of the mobile unit using velocity information 
and/or route or schedule information that the mobile unit follows. . . . This 
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information can be combined with location-related information regarding the next 
location node and the estimated time to travel to it. From this data, the link 
scheduler 70 can be used in determining that a particular channel will go off line, 
as well as network channels that will become available. After this determination is 
made, the link scheduler 70, at step 226, informs the link selector 64 of the date 
and time when the currently utilized network channel will go off line. The link 
selector 64 is able to use this information in controlling the switching from the 
currently used network channel to a new or different selected channel. 

Thus, the Spaur reference nowhere discloses how scanning of other channels is performed or 
hopping between a channel supporting the TCP connection within a wireless local area network 
(WLAN) and other channels of the WLAN to avoid excess latency. Thus, the Spaur reference 
fails to disclose the requirements, inter alia, of claim 20 of, "memory operably coupled to the 
processing module, wherein the memory stores operational instructions that cause the processing 
module to: . . . when the network interface protocol channel scan request is received, hop 
between a channel supporting the TCP connection within the WLAN a wireless local area 
network (WLAN) and other channels of the WLAN to avoid excess latency in acknowledging 
receipt of a datagram of the at least one datagrams or a portion of the datagram during scanning 
of the other channels of the WLAN." 

The Gwon reference also fails to disclose or suggest the requirements, inter alia, of claim 
20 of, "memory operably coupled to the processing module, wherein the memory stores 
operational instructions that cause the processing module to: . . . when the network interface 
protocol channel scan request is received, hop between a channel supporting the TCP connection 
within the WLAN a wireless local area network (WLAN) and other channels of the WLAN to 
avoid excess latency in acknowledging receipt of a datagram of the at least one datagrams or a 
portion of the datagram during scanning of the other channels of the WLAN." The Gwon 
reference describes a procedure for minimizing the handoff latency resulting from standard 
Mobile IP handoff procedures, as stated at column 2, lines 36 through 39. The Gwon reference 
describes that in order to prevent L3 handoff latency, a pre -registration handoff method allows 
the L3 handoff to begin even before the L2 handoff begins, as stated at column 2, lines 57 
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through 65. As stated in column 4, lines 13 through 35, IP tunnels are established between a 
source node and a set of candidate nodes. The tunnels are used to forward data to the mobile 
node after a communication link between the mobile node and the source node goes down. Once 
a target node is identified from the candidate nodes, using the tunnel from the source node to the 
target node, the mobile node keeps IP data communication with the source node after the L2 
handoff but before the L3 handoff Again at column 9, lines 35 through 51, the Gwon reference 
explains that: 

With the tunnel that remains up [between the old FA (oFA) and new FA (nFA)], 
the MN can receive data from the oFA while on the nFA's subnet. Thus, the 
tunnel between oFA and nFA allows the MN to continue using the oFA for data 
communication while on the nFA's subnet. . . . The MN must eventually perform 
a formal Mobile IP registration illustrated in FIG. 1 after an L2 link with the nFA 
is established, but this can be delayed as required by the MN. Until the MN 
performs registration, a new FA and an old FA will setup and move a tunnel as 
required to give MN continued connectivity. 

Thus, the Gwon reference merely discloses tunneling to a MN from an old FA while on a new 
FA subnet before a form Mobile IP registration by the MN. As such, the Gwon reference fails to 
disclose the requirements, inter alia, of claim 20 of, "memory operably coupled to the processing 
module, wherein the memory stores operational instructions that cause the processing module to: 
. . . when the network interface protocol channel scan request is received, hop between a channel 
supporting the TCP connection within the WLAN a wireless local area network (WLAN) and 
other channels of the WLAN to avoid excess latency in acknowledging receipt of a datagram of 
the at least one datagrams or a portion of the datagram during scanning of the other channels of 
the WLAN." 

The combination of the references also fails to suggest the requirements of claim 20. 
There is no suggestion to revise the references to meet the requirements of claim 20 because 
neither reference discloses or realizes the problems addressed by the embodiments of the present 
invention that if a station is scanning other channels for a significant period of time (e.g., a few 
hundred milliseconds), TCP/IP may view this absence of support as congestion and evoke the 
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multiplicative decrease congestion avoidance algorithm. As such, the combination of the 
reference fails to suggest the requirements, inter alia, of claim 20 of, memory operably coupled 
to the processing module, wherein the memory stores operational instructions that cause the 
processing module to: . . . when the network interface protocol channel scan request is received, 
hop between a channel supporting the TCP connection within the WLAN a wireless local area 
network (WLAN) and other channels of the WLAN to avoid excess latency in acknowledging 
receipt of a datagram of the at least one datagrams or a portion of the datagram during scanning 
of the other channels of the WLAN." 

The dependent claims 21 through 23 add further patentable matter to Claim 20 and thus 
are further differentiated and patentable under 35 U.S. C. §103 over the Spaur reference in view 
of the Gwon reference. 

Independent Claim 24 and dependent Claims 25 through 28 

Neither the Spaur reference nor the Gwon reference disclose or suggest the requirements, 
inter alia, of claim 24 of, "memory operably coupled to the processing module, wherein the 
memory stores operational instructions that cause the processing module to: receive a channel 
scan request in accordance with a transport application; determine whether one of the datagrams 
is being received when the channel scan request is generated; when the one of the datagrams is 
being received when the channel scan request is received, scan at least one other channel of the 
plurality of channels, but less than all of the plurality of channels; after scanning the at least one 
other channel, tune to the one of the plurality of channels and transmitting at least one outbound 
datagram; and scanning at least another channel of the plurality of channels." 

With respect to the Spaur reference, as stated above with respect to Independent Claim 
14, the Spaur reference discloses that no transfer of information occurs until the link scheduler 
70 determines the identity of other network channels that are becoming available for selection, 
based on current location of the mobile unit and the anticipated change in location of the mobile 
unit, at column 13, lines 8 through 16. Thus, the Spaur reference discloses only determining 
whether to initiate transfer on one or more selected network channels or determining an identity 
of other network channels based on location of the mobile unit to transfer the particular 
information. This aspect of the Spaur reference actually teaches away from claim 24. The Spaur 
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reference nowhere even discloses a request for scanning or how scanning of the channels is 
performed. Thus, the Spaur reference fails to disclose the requirements, inter alia, of claim 24 
of, "memory operably coupled to the processing module, wherein the memory stores operational 
instructions that cause the processing module to: when the one of the datagrams is being received 
when the channel scan request is received, scan at least one other channel of the plurality of 
channels, but less than all of the plurality of channels; after scanning the at least one other 
channel, tune to the one of the plurality of channels to transmit at least one outbound datagram; 
and scanning at least another channel of the plurality of channels." 

With respect to the Gwon reference, as stated above with respect to Independent Claim 
14, the Gwon reference merely describes a procedure for minimizing L3 handoff latency using a 
pre-registration handoff method that allows the L3 handoff to begin even before the L2 handoff 
begins, as stated at column 2, lines 57 through 65. Thus, the Gwon reference nowhere discloses 
a request for scanning or how scanning of the channels is performed. As such, the Gwon 
reference fails to disclose the requirements, inter alia, of claim 24 of, "memory operably coupled 
to the processing module, wherein the memory stores operational instructions that cause the 
processing module to: when the one of the datagrams is being received when the channel scan 
request is received, scan at least one other channel of the plurality of channels, but less than all of 
the plurality of channels; after scanning the at least one other channel, tune to the one of the 
plurality of channels to transmit at least one outbound datagram; and scanning at least another 
channel of the plurality of channels." 

The combination of the references also fails to suggest the requirements of claim 24. As 
explained above, both the Spaur reference and the Gwon reference merely disclose handoff 
procedures and fail to even disclose the requirements of claim 24 as explained above. In 
addition, there is no suggestion to revise the references to meet the requirements of claim 24 
because neither reference discloses or realizes the problems addressed by the embodiments of the 
present invention that if a station is scanning other channels for a significant period of time (e.g., 
a few hundred milliseconds), TCP/IP may view this absence of support as congestion and evoke 
the multiplicative decrease congestion avoidance algorithm. As such, the combination of the 
reference fails to suggest the requirements of claim 24. 
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The dependent claims 25 through 28 add further patentable matter to Claim 24 and thus 
are further differentiated and patentable under 35 U.S.C. §103 over the Spaur reference in view 
of the Gwon reference. 

Independent Claim 29 and dependent Claims 30 through 32 

Neither the Spaur reference nor the Gwon reference disclose or suggest the requirements, 
inter alia, of claim 29 of, "memory operably coupled to the processing module, wherein the 
memory stores operational instructions that cause the processing module to: when a 
Transmission Control Protocol (TCP) connection is established between a source and a 
destination, receive a network interface protocol channel scan request; and when the network 
interface protocol channel scan request is received, hop between a channel supporting the TCP 
connection within a wireless local area network (WLAN) and other channels of the WLAN and 
transmitting on the channel supporting the TCP connection to avoid excess latency in 
acknowledging receipt of a datagram of the at least one datagrams or a portion of the datagram 
during scanning of the other channels of the WLAN." 

With respect to the Spaur reference, as stated above with respect to Independent Claim 
20, the Spaur reference discloses that no transfer of information occurs until the link scheduler 
70 determines the identity of other network channels that are becoming available for selection, 
based on current location of the mobile unit and the anticipated change in location of the mobile 
unit, at column 13, lines 8 through 16. Thus, the Spaur reference discloses only determining 
whether to initiate transfer on one or more selected network channels or determining an identity 
of other network channels based on location of the mobile unit to transfer the particular 
information. This aspect of the Spaur reference actually teaches away from claim 29. The Spaur 
reference nowhere even discloses how scanning of other channels is performed or hopping 
between a channel supporting the TCP connection within a wireless local area network (WLAN) 
and other channels of the WLAN to avoid excess latency. Thus, the Spaur reference fails to 
disclose the requirements, inter alia, of claim 29. 

With respect to the Gwon reference, as stated above with respect to Independent Claim 
14, the Gwon reference merely describes a procedure for minimizing L3 handoff latency using a 
pre-registration handoff method that allows the L3 handoff to begin even before the L2 handoff 
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begins, as stated at column 2, lines 57 through 65. Thus, the Gwon reference nowhere discloses 
disclosing how scanning of other channels is performed or hopping between a channel 
supporting the TCP connection within a wireless local area network (WLAN) and other channels 
of the WLAN to avoid excess latency. . As such, the Gwon reference fails to disclose the 
requirements of claim 29. 

As explained above, the combination of the references also fails to suggest the 
requirements of claim 29. Both the Spaur reference and the Gwon reference merely disclose 
handoff procedures without disclosing how scanning of other channels is performed or hopping 
between a channel supporting the TCP connection within a wireless local area network (WLAN) 
and other channels of the WLAN to avoid excess latency. In addition, there is no suggestion to 
revise the references to meet the requirements of claim 29 because neither reference discloses or 
realizes the problems addressed by the embodiments of the present invention that if a station is 
scanning other channels for a significant period of time (e.g., a few hundred milliseconds), 
TCP/IP may view this absence of support as congestion and evoke the multiplicative decrease 
congestion avoidance algorithm. As such, the combination of the reference fails to suggest the 
requirements of claim 29. 

The dependent claims 30 through 32 add further patentable matter to Claim 29 and thus 
are further differentiated and patentable under 35 U.S.C. §103 over the Spaur reference in view 
of the Gwon reference. 
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Conclusion 

For the above reasons, the foregoing response places the Application in condition for 
allowance. Therefore, it is respectfully requested that the rejection of the claims be withdrawn 
and full allowance granted. Should the Examiner have any further comments or suggestions, 
please contact Jessica Smith at (972) 240-5324. 

Respectfully submitted, 
Garlick, Harrison & Markison 

Dated: January 15, 2008 /Jessica W. Smith/ 

Jessica W. Smith 
Reg. No. 39,884 

Garlick, Harrison & Markison 
P.O. Box 160727 
Austin, TX 78716-0727 
Phone: (972)240-5324 
Fax: (469)366-6731 
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